Waiting for #13 and #15

Would it maybe make sense just to expose the loudness to the plugin as a property of the model, and let the plugin apply the gain at the same time as it does the output leveling?

I was hoping to actually get rid of the gain adjustment step completely in the NAM code, since it isn't currently doing anything - this would allow us to remove an extra buffer copy. Not super significant compared to the model simulation itself, but every little bit helps.

I am not sure but I think there is quite a bit of redundant buffer copying code in the NAM plugin src, an issue for another day (and another repo)

Would it maybe make sense just to expose the loudness to the plugin as a property of the model, and let the plugin apply the gain at the same time as it does the output leveling?

I was hoping to actually get rid of the gain adjustment step completely in the NAM code, since it isn't currently doing anything - this would allow us to remove an extra buffer copy. Not super significant compared to the model simulation itself, but every little bit helps.

Not sure. Here's my thinking on it:

• Whether the model's output should be normalized feels like a mode of operation for the model object itself. Which is why I think it makes sense for it to own it & be used via an abstraction like SetNormalize().
• Some models won't have this information available. Instead of pushing that complexity & handling out to the code using the model, SetNormalize() keeps it as a matter that's internal to the model. One could output the "target loudness", but it wouldn't be clear whether the model actually was this loud or if it was just outputting a "placeholder". If you're thinking of something like double GetLoudness(), happy to hear you out.
• FWIW, this doesn't introduce an additional copy (just uses the one that's there), and the implementation of applying normalization can easily be changed to being part of _process_core_() in a number of ways. At least the current implementation should add a negligible amount of compute over the previous code. ATM, my thinking is "[...] premature optimization..."--so if there really is a performance boost and you want it, I'm happy to field a PR that changes the implementation. I suspect it'll add complexity to the codebase if I code it up, but perhaps yours would be nice & clean.

Happy to hear both your thoughts.

• FWIW, this doesn't introduce an additional copy

It doesn't, no, but it does prevent removing the existing copy at both input and output for gain adjustment (that isn't currently required, because the plugin handles I/O gain adjustment).

My plan was to completely get rid of "_input_post_gain" and "_core_dsp_output" and read/write directly from the buffer pointers passed to process. Removes two copies.

• FWIW, this doesn't introduce an additional copy

It doesn't, no, but it does prevent removing the existing copy at both input and output for gain adjustment (that isn't currently required, because the plugin handles I/O gain adjustment).

It doesn't prevent it. The implementation of applying loudness could simply involve applying the gain at the point where the core dsp writes to the buffer. Or, an in-place multiplication could be done, which might read a little cleaner, but also might not compile-time optimize.

My plan was to completely get rid of "_input_post_gain" and "_core_dsp_output" and read/write directly from the buffer pointers passed to process. Removes two copies.

Agreed--this is a good thing to do.

The implementation of applying loudness could simply involve applying the gain at the point where the core dsp writes to the buffer.

True. Still one extra multiplication pass over having the plugin apply it with output level, though. But I agree that this get into small potatoes optimization, so I'll shut up about it for now :-)